PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 3/USEnet 3.066

Text File | 1988-04-08 | 23.9 KB | 612 lines | [TEXT/ttxt]

29-Sep-87 08:56:57-PDT,25040;000000000001
Date: Sat 12 Sep 87 11:07:03-EDT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V3 #66

Usenet Mac Digest     Friday, September 11, 1987     Volume 3 : Issue 66

Today's Topics:
     New master pointer query.
     Porting C programs to the Mac
     Re: Which Is Better: DMCS or Studo Session? (Mac)
     HyperCard annoyances
     Broken mouse...can it be fixed?
     MenuBar in HyperCard
     Converting Mac format to GEM
     LightSpeed Pascal Problem
     Re: Hypercard lossage
     Re: Which Is Better: DMCS or Studo Session? (Mac)
     Re: Broken mouse...can it be fixed?
     Ukrainian version of the Cyrillic Alphabet
     File I/O in HyperTalk
     Re: Flames about Multifinder

----------------------------------------------------------------------

From: [e-mail] (William C. Bauldry)
Subject: New master pointer query.
Date: 4 Sep 87 13:53:24 GMT
Organization: UNC Educational Computing Service

 Having little printed resources available now... Since addresses have
jumped to 32 bits how is the master pointer handled (bad pun)? The old
format stole the high order byte for flags, i.e. handle locked, etc.
Could some kind soul enlighten me and raise my consciousness to the new
type ? thanks in advance.

Bill


------------------------------

From: [e-mail] (Tom Cunningham)
Subject: Porting C programs to the Mac
Date: 4 Sep 87 16:59:20 GMT
Organization: Motorola Inc. Austin, Tx

I am new to this newsgroup and I wonder if anyone can give me some
pointers. We have some software written in C that currently runs on
Berkeley Unix (Sun and VAX), PC/MS-DOS, and VAX/VMS.  We are considering
a port to the Macintosh II.  One application is about 16,000 lines of
code, 15 modules (separately compilable files).  The other is
approximately 30,000 lines of code, 25 modules.  These applications are
written to use the "standard I/O" (stdio) library routines:  fopen,
fclose, fread, fwrite, printf, scanf, etc. The larger application does
some screen handling using BIOS on the PC, curses under Unix, and SMG
under VMS.  Both make use of argc and argv.

We have a Mac II (or is that Mac ][?) with Lightspeed C, which provides
a very interesting development environment.  From what I can gather,
doing a straight port to this machine is not possible.  There is no
support for argc/argv, and a symbolic representation for a directory
path for placing input and output files doesn't appear to exist (perhaps
the notion of path doesn't exist?).  I am sure there are other
differences that I haven't run into yet.

My question is this: is there something, a product or whatever, that
would allow one to do a (fairly) straightforward port?  I guess I'm
thinking of a "shell" that you could wrap around the application to
provide command line input, paths, and what have you.  It sounds like
Manx might give you something like that with Aztec C, but it also sounds
like it's only for the development environment; can you link it in to
your user program? Before you cynics out there say "buy A/UX" (Apple
Unix, right?), I'm just thinking that our customers might not want to
buy a new operating system just to use our software.  They probably want
to use their old Macintosh software too.

Don't get me wrong about the Mac; I like the interface, and if we have
to delve into the Toolbox then so be it.  But I am trying to explore
expeditious alternatives, and if we can do something to keep our
software a little more portable that would be great.  Thanks for any
light you can shed.


Tom Cunningham seismo!ut-sally!oakhill!tomc sun!oakhill!tomc
--

Tom Cunningham     "Good, fast, cheap -- select two."
USPS:  Motorola Inc.  6501 William Cannon Dr. W.  Austin, TX 78735-8598
UUCP:  {ihnp4,seismo,ctvax,gatech}!ut-sally!oakhill!tomc
       sun!oakhill!tomc
Phone: [phone]


------------------------------

From: [e-mail] (David Phillip Oster)
Subject: Re: Which Is Better: DMCS or Studo Session? (Mac)
Date: 4 Sep 87 22:08:53 GMT
Organization: School of Education, UC-Berkeley

DMCS version 2.0, supporting the Sonata (postScript) font, MIDI, and
cutting and pasting music to the clipboard (like into MacDraw) has been
out for at least 4 months. Electronic Arts wazs very good about mailing
people an upgrade offer. Many problems were fixed. Printing is
drastically improved. The manual describes a user interface for creating
your own DMCS sounds.

To use DMCS with MIDI, you tell DMCS which serial port the optional MIDI
adapter is on. You then decorate the sheet music with things like DMCS's
change voice commands, that tell it which MIDI channel to send that
staff on, and which sound to tell the synthesizer to use.  I believe it
can generate 8 staves of MIDI data with 256 different numbered sounds
(MIDI patch change commands). (By comparison, Studio Session does 6
staves, and as many different sounds as will fit in memory (figure 30k
per sound.) Both will let you use the same sound many times in a piece
(of course.)

You can play on the keyboard and DMCS will auto-correct your tempo, to
turn your playing into sheet music. (You'll need an optional MIDI
adapter (DMCS 2.0 comes with a discount offer for one, inside the
package.) However, you need to play in such a stilted style, that it
isn't clear how useful this is. You can also read files from OpCode's
MIDI sequencer, which should have much better auto-correction. (I
haven't used it, I'd like a recommendation. Anybody out there use it and
like it?) You can mix MIDI voices and Mac voices.

To use Sonata on a LaserWriter, you'll need to buy the postScript
version of Sonata from Adobe. (DMCS 2.0 comes with a discount offer for
one, inside the package.)

Studio Session is much easier to use and sounds tons better than DMCS
(unless DMCS is driving a 6 channel sampler over MIDI :-)  DMCS beats
Studio Session on printing though.  The file format of Studio Session
has been published, and DMCS 2.0 can read and write MIDI data to disk in
a standard format.  Has anyone written a DMCS <-> Studio Session
converter? (If yes, please tell me about it. If no, let me know, and
I'll do it.)

DMCS was written by a programmer who doesn't seem to like the Mac much.
Although it looks like a Mac program, it subtly does not feel like one.
For example, if I were writing it, clicking on # (sharp sign modifier)
would turn off b (flat sign modifier), and clicking on # again would
turn # off.  Instead, you have to click on <clear modfiers>.  You pick a
short note value, and drag right, at the time you create the note, to
lengthen its tempo. I usually find that even if I drag the mouse to the
margin of the screen, I can't get the tempo I want. You probably can
type "q" to change the currently selected note to a quarter note, "h"
for half, etc. but I am not sure.  (It is a big, complicated program,
and I always discover new things about it whenever I sit down with it.)

There is still a bogus measure after the last note in the piece drawn on
the screen, but at least now it doesn't print.

I found Electronic Arts very sensitive to complaints like these. I wrote
them a letter, and the DMCS (Mac) programmer called me to talk things
over.

I really like being able to cut a few measures of music and paste them
into a page layout program.

If I had written it, I'd have had a tighter association between the
notes and the lyrics. As it stands now, there is none, and you have to
type spaces to get the lyrics to lin up under the notes. If you move a
note,  you must adjust the lyrics by hand.

The guitar tablature font is neat.

Conclusion: Studio Session is the better buy for those who never print.
(particularly if you also buy the the MacNifty (now Impulse) audio
digitizer: great sampled sound, like 30 different instruments in a
single piece, (although only 6 running at once.) lousy printing though
(at least in the version I've got.) Because the Mac version was done
before that for any other machine, it feels "right" to a mac user. My
wife has just completed a cassette, done in large part, in Studio
Session.

DMCS is the better buy for printing sheet music, and controlling a few
MIDI instruments.  To control many MIDI instruments, you'll need a
program that is just a sequencer.  I also like patch librarians that use
the big (by music standards) screen of the mac to give your synthesizer
a decent user interface. Because DMCS is part of a family of Electronic
Arts DMCS products, the user interface feels subtly off to a mac user.
My wife has just completed collaborating on a song book done in DMCS.

It is a shame that you can't cut and paste between DMCS and Studio
Session. If Studio Session could read/write MIDI sequencer data, then
the two would work together. On the other hand, the file format of
Studio Session has been published, while that of DMCS has not (correct
me if I am wrong.) A simple tool, that may already exist, would let them
read/write files that the other could use.

--- David Phillip Oster            --My Good News: "I'm a perfectionist."
Arpa: [e-mail] --My Bad News: "I don't charge by the hour."
Uucp: {seismo,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu

------------------------------

From: [e-mail] (Charles C. Allen)
Subject: HyperCard annoyances
Date: 5 Sep 87 00:09:25 GMT
Organization: Purdue Univ. Phys Dept, W.Lafayette, IN

HyperCard is a brilliant idea, but as someone already mentioned, the
interface leaves alot to be desired.

Here are some "features" that really cause me to gnash my teeth:

    *    All cards are 512x342

    This is silly.  I can see requiring that all cards with the
    same background be the same size, or maybe even all cards in
    the same stack, but ALL cards?  Just go through the stacks
    that come with HyperCard and you'll find several that would
    benefit from a smaller card size.  A larger card size would be
    useful also.  The ROM has this neat control called a scroll
    bar that does wonders in these situations.

    *    No way to abort changes to stacks

    GROWF!  This is probably the worst thing about HyperCard.  It
    is the ONLY program on the Mac I've run across that silently
    saves all your changes.  Manually making a "backup" stack is
    error-prone and unwieldy.

    *    One stack open at a time

    Here we are in the age of MultiFinder, multi-megabyte Macs,
    and HyperCard won't allow more than one open stack.  Sigh.

    *    Home Card?

    Maybe it's just me, but I can't really figure out why the Home
    Card is necessary.  It's sort of a Finder for stacks.  Yes, it
    has search paths and the "user level" card in there also, but
    basically Home Card exists for opening stacks.  Why not just
    make an SFGetFile dialog that displays icons?  Say, that would
    be a nice idea for any application....  The preferences and
    search paths could be subsumed by menu items.  If more than
    one stack could be open at a time, this wouldn't be as bad.

There are a few bugs that are rather annoying also:

    X    Open up a stack on a screen bigger than 512x342 (I have an
    Apple RGB monitor on my Mac II).  Open a desk accessory, and
    place it off to the side.  Now click on the card stack window
    to re-activate it.  Now click on the card stack window to
    re-activate it.  Now click... what is this?  It won't come to
    the foreground!  Oddly, you CAN activate the stack window by
    clicking on one of the companion (Tools, Patterns, Messages)
    windows, but that's hardly intuitive.

    On a related note, notice that the card stack title bar always
    looks "de-activated" when one of the companion windows are
    out.  I don't know about you folks, but when a window looks
    de-activated, I don't expect it to respond to clicks except by
    becoming active.

    X    The "visual effect" command has no effect when more than one
    bit plane is in use.

And here's an oddity about background buttons and fields that confuses
me:

    ?    A background field has its position and whatnot stored
    "globally".  The text of the field, however, is local to each
    card with that background.  A background button has its
    position and whatnot stored "globally".  The hilite state of the
    button is also global.

    Both cases sort of make sense, but so do the cases where the
    text of background fields is global, and the hilite state of a
    background button is local.  It's rather confusing that fields
    and buttons are different in this regard.  I would prefer
    consistency one way or the other.  Even better, have this as
    an option in the Button info and Field info dialogs.

    You can, of course, simulate the "other" behavior in either
    case.

I'll hold off on my other comments 'til I've had a chance to read the
rumored HyperCard Script Language Guide.  Back to simultaneously
gnashing my teeth and having a grand time in HyperCard....

Charlie Allen        [e-mail]


------------------------------

From: [e-mail] (Marty Lee)
Subject: Broken mouse...can it be fixed?
Date: 4 Sep 87 14:37:13 GMT
Organization: Rick's Home-Grown UNIX; Portland, OR.


The wire that goes to the mouse button has decided to go open. Now the
button will not work unless I wiggle the strain relief. After taking the
mouse apart, it can only be in the strain relief. (I have a Mac+, the
mouse is NOT an ADB type.)

Any suggestions?  Apple wants $100 for a new one!  Any good second
source mouses around?

Thanks in advance,

Marty Lee
--
tektronix!reed!omen!bucket!martyl  (Marty Lee)


------------------------------

From: [e-mail] (Patrick van Kleef)
Subject: MenuBar in HyperCard
Date: 4 Sep 87 21:21:26 GMT
Organization: V.U. Informatica, Amsterdam, the Netherlands

Has any of you HyperCard programmers found a way to alter the HyperCard
menubar to a custom menubar providing the users with programmerd
options? If so, please disclose this feat. I'm stuck!


------------------------------

From: [e-mail] (Gareth Howell)
Subject: Converting Mac format to GEM
Date: 1 Sep 87 16:08:47 GMT
Organization: STC Network Systems, Stevenage, Herts. UK


Does anyone know of any utilities that will permit the conversion of MAC
format documents, diagrams etc to GEM format for use on an IBM pc clone?
Gareth

--
Gareth Howell  <[e-mail]>  G6KVK @ IO91VX
ICL Network Systems, Private Networks Business Centre
London Road, Stevenage, Herts, England, SG1 1YB    Tel:[phone]
[e-mail], idec![e-mail]


------------------------------

From: [e-mail] (Karl B. Klashinsky)
Subject: LightSpeed Pascal Problem
Date: 4 Sep 87 14:05:57 GMT
Organization: University of Victoria, Victoria B.C. Canada


I'm working on porting a Turbo Pascal Unit to LightSpeed Pascal, and
I've hit a catch.  In the Turbo Unit, the high bit of an integer is set
with

    foo := $8000 ;    {set high bit -- value is -32768}

But, LightSpeed won't accept that -- it complains that the "constant
(whose value is -32768) is out of range".

I thought that the range of ints was supposed to be -32768 to +32767.
I've tried the obvious "hacks", with no luck.  For instance:

    i := -32767 ;
    i := i-1 ;    {nope -- int overflow} or
    i := -16384 ;
    i := 2 * i ;    {ditto}

I don't know why (yet) but the Unit does not work properly if "foo" does
not have the high bit set.

I'm using LSP 1.0.  Can anyone please help me?  Will a more recent
version of LSP help?

Karl

--
Karl Klashinsky                         "Gee, I wish I could find a
University of Victoria                  neat quote to put in my
British Columbia, Canada                .signature"
                                                             <me>
e-mail:    {uw-beaver, ubc-vision}!uvicctr!klash


------------------------------

From: [e-mail] (Eirik Fuller)
Subject: Re: Hypercard lossage
Date: 5 Sep 87 10:02:10 GMT
Organization: Tektronix, Inc., Beaverton, OR.

Sorry if this has been discussed already ... has anyone gotten hypercard
to dial a modem at 2400 baud?  Does the latest version of UW do any
dialing?

Please reply via email if possible; I will post a summary if
appropriate.

(crl.tek.com can be reached from arpa via relay.cs.net)


------------------------------

From: [e-mail] (Christopher Chow)
Subject: Re: Which Is Better: DMCS or Studo Session? (Mac)
Date: 5 Sep 87 16:23:06 GMT
Organization: Cornell Theory Center, Cornell University, Ithaca NY

Well, if you only think that DMCS 2.0 has been out for at least 4 months
then Electronics Arts isn't very good a mailing out upgrad notices.
I've been using DMCS 2.0 for almost a year now!

While DMCS 2.0 is a vast improvement over DMCS 1.0, it does have a few
problems:

1.  The midi implementation seems to be a afterthought.  For example, in
    midi input mode, try typing in a chord.  On my copy the chord just
    gets longer and longer until it takes a duration value equal to the
    length of the measure.  I.e., play a C maj chord and hold it for one
    quarter note -- in a 4/4 measure you'll see the chord cycle from
    quarters, to whole notes.

2.  It uses the PACE copy protection system.  This system uses encrypted
code
    segments, while drastically slows down program loading time,
    especially if you're running of a hard disk.  Even worse, if you
    have a debugger running (Macsbugs/TMOM), it'll reboot the computer
    w/o unmounting all volumes, meaning that your hard disk has to go
    through a lengthly volume verification process before you can reboot.

    Luckily, there is a public domain DA, "FixJT" which can remove this
    protection -- however Opcode systems has now implemented something
    which prevents FixJT from working correctly, so FixJT might not work
    w/ DMCS anymore.  BTW, on my system, the unprotected version of DMCS
    2.0 loads in ~10 sec, the protected ~25 sec.

3.  Printing dosen't seem to work under SuperLaserSpool.  Since I don't
have
    a LW or LW+, I didn't buy Adobe's Sonata laser font.  But, shouldn't
    the Sonata screen font be substituted?  Well, this summer, when I
    has acess to a LW+, I tried to print from DMCS 2.0 thru
    SuperLaserSpool and I got no output!

All things considered, I wouldn't recommend DMCS 2.0 for anything except
for a notation package for Opcode's Sequencer 2.5 and possibly teaching
childern a bit about music.  If I had to do it all again, I probably
would also go with MasterTracks Pro instead of Opcode, thereby not using
DMCS at all.

A word regarding DMCS support - I did try to call Electronic Arts
several months ago about DMCS, but noone every even answered the phone!

Christopher Chow
/---------------------------------------------------------------------------\
| Internet:  [e-mail] (128.84.248.35 or 128.84.253.35)   |
| Usenet:    ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow    |
| Bitnet:    [e-mail]                                           |
| Phone:     [phone],  USPS: 7122 N. Campus 7, Ithaca, NY 14853      |
| Delphi:    chow2            PAN:  chow                                    |
\---------------------------------------------------------------------------/


------------------------------

From: [e-mail] (Phil Reese)
Subject: Re: Broken mouse...can it be fixed?
Date: 5 Sep 87 17:16:30 GMT
Organization: School of Education, UC-Berkeley

I've had very good luck fixing flaky mouses.  You need a bit of
experience with a soldering iron and some electrical tape.  All of the
mouses that I've fixed have had one or more broken wires in or near the
strain relief coming out of the mouse shell.  The simple way is to
disassemble the mouse and remove the wire from the mouse inards.  Now
carefully but firmly twist on the strain relief to move it up the cable.
 The strain releif is not permanent on the wire though it may seem that
way on first attempt.  Some lubricating oil, sparingly applied may help.
 Once the strain releif is further up the cable reconnect the mouse wire
to the internals.  Now by moving the mouse on a running Mac try to
determine where the break is in that first 4-6" of wire.  Pinpoint it
and then dissassemble the wire again.  Cut off the wire just above the
break, strip the insulation back and strip each wire.  On the piece cut
off will be the connector for connecting to the socket in the mouse,
carefully cut the wires near the socket and switch components.  Leave
enough room to strip the wires and solder and tape the joints, about 2+"
is ok.  Strip these wires and match colors with the long wire and solder
the connections.  Carefully tape each connection and test out the fixed
wire.  Did it work?  Reassemble and happy mousing!

Use this suggestion at your own risk!  Not responsible for 'beyond
repair mouses'.

Phil Reese SESAME/School of Ed UC Berkeley [e-mail]


------------------------------

From: [e-mail] (Gordon Goodman)
Subject: Ukrainian version of the Cyrillic Alphabet
Date: 5 Sep 87 17:37:44 GMT
Organization: Rochester Institute of Technology, Rochester, NY

I am looking for a Ukrainian version of the cyrillic alphabet for the
Mac.   The font will be printed on an Imagewriter.   For those of you
who are not  familliar with cyrillic, the Russian alphabet, what comes
to mind first when people think of cyrillic, is not the same as the
Ukrainian cyrillic  alphabet.  And that is the problem.  There are
several Russian versions around but they cannot be used to write
Ukranian.

A lead on a source for a modestly priced font or one in the public
domain would be much appreciated.  If possible, I would prefer to locate
rather than create a Ukrainian version.

Nosdorolya,


------------------------------

From: [e-mail] (Dan Winkler)
Subject: File I/O in HyperTalk
Date: 4 Sep 87 08:11:15 GMT
Organization: Apple Computer, Inc., Cupertino, USA

Here is an example of file I/O in HyperTalk that imports and exports
text.  The open file command does not use the documents search path --
it simply passes the name you gave, which could include a path, to
FSOpen.  If the file does not exist, HyperTalk automatically creates it
and then opens it.

on mouseUp
  -- export text
  put the short name of this stack & " text" into fileName
  ask "Export text to what file?" with fileName
  if it is empty then exit mouseUp
  put it into fileName
  open file fileName
  go to first card
  repeat for the number of cards
    repeat with i = 1 to the number of fields
      write field i to file fileName
      write tab to file fileName
    end repeat
    go to next card
  end repeat
  close file fileName
end mouseUp

on mouseUp
  -- import text
  ask "Import text from what file?"
  if it is empty then exit mouseUp
  put it into fileName
  open file fileName
  repeat
    doMenu "New Card"
    repeat with i = 1 to the number of fields
      read from file fileName until tab
      if it is empty then -- end of file
        if i = 1 then doMenu "Delete Card"
        close file fileName
        exit mouseUp
      end if
      delete last char of it  -- kill tab
      put it into field i
    end repeat
  end repeat
end mouseUp


------------------------------

From: [e-mail] (Larry Rosenstein)
Subject: Re: Flames about Multifinder
Date: 4 Sep 87 18:40:13 GMT
Organization: Advanced Technology Group, Apple Computer

Multifinder does not require 2Mb.  I am using it now on a 1Mb Mac Plus.
136K allocated to MacTerminal, 160K to Finder, 355K to the System, with
373K to run something else.

Multifinder should be equivalent (memory-wise) to running Switcher with
the Finder in one partition.  One important advantage of Multifinder is
that you can give the Finder only 160K and it can still get more memory
(eg, for disk copies) from Multifinder as needed.

I suppose that you could use one of the other Finder-substitutes that
might require less than 160K, and free up more memory that way.

>(I like Switcher A LOT.  As far as  I am concerned,  it is
>the best piece  of software Apple ever produced,  and  I use it  quite
>frequently.).  As I see it, there are only a few alternatives:

I never used Switcher at all because there was too much overhead in
using it.  On the other hand, I am using Multifinder on all my machines
(2 Mac Pluses, and 1 Levco Prodigy 4).


--
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: [e-mail]

------------------------------

End of Usenet Mac Digest
************************
-------
-------